<!DOCTYPE html>
<html>

<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
	<meta name="theme-color" content="#33474d">
	<title>为什么使用 Redis及其产品定位 | 失落的乐章</title>
	<link rel="stylesheet" href="/css/style.css" />
	
      <link rel="alternate" href="/atom.xml" title="失落的乐章" type="application/atom+xml">
    
</head>

<body>

	<header class="header">
		<nav class="header__nav">
			
				<a href="/archives" class="header__link">Archive</a>
			
				<a href="/tags" class="header__link">Tags</a>
			
				<a href="/atom.xml" class="header__link">RSS</a>
			
		</nav>
		<h1 class="header__title"><a href="/">失落的乐章</a></h1>
		<h2 class="header__subtitle">技术面前，永远都是学生。</h2>
	</header>

	<main>
		<article>
	
		<h1>为什么使用 Redis及其产品定位</h1>
	
	<div class="article__infos">
		<span class="article__date">2017-10-12</span><br />
		
		
			<span class="article__tags">
			  	<a class="article__tag-link" href="/tags/Redis/">Redis</a>
			</span>
		
	</div>

	

	
		<h2 id="传统MySQL-Memcached架构遇到的问题"><a href="#传统MySQL-Memcached架构遇到的问题" class="headerlink" title="传统MySQL+ Memcached架构遇到的问题"></a>传统MySQL+ Memcached架构遇到的问题</h2><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：</p>
<ol>
<li>MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。</li>
<li>Memcached与MySQL数据库数据一致性问题。</li>
<li>Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。</li>
<li>跨机房cache同步问题。</li>
</ol>
<h2 id="众多NoSQL百花齐放，如何选择"><a href="#众多NoSQL百花齐放，如何选择" class="headerlink" title="众多NoSQL百花齐放，如何选择"></a>众多NoSQL百花齐放，如何选择</h2><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题</p>
<ol>
<li>少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。</li>
<li>海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。</li>
<li>这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。</li>
<li>Schema free，auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。</li>
</ol>
<p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。</p>
<h2 id="Redis适用场景，如何正确的使用"><a href="#Redis适用场景，如何正确的使用" class="headerlink" title="Redis适用场景，如何正确的使用"></a>Redis适用场景，如何正确的使用</h2><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢？</p>
<h2 id="Redis与Memcached的比较"><a href="#Redis与Memcached的比较" class="headerlink" title="Redis与Memcached的比较"></a>Redis与Memcached的比较</h2><h3 id="1-网络IO模型"><a href="#1-网络IO模型" class="headerlink" title="1. 网络IO模型"></a>1. 网络IO模型</h3><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接描述字pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。</p>
<p><figure class="figure"><img src="https://github.com/hcldirgit/image/blob/master/%E4%B8%BA%E4%BB%80%E4%B9%88%E4%BD%BF%E7%94%A8%20Redis%E5%8F%8A%E5%85%B6%E4%BA%A7%E5%93%81%E5%AE%9A%E4%BD%8D/01.jpeg?raw=true" alt=""></figure></p>
<p>（Memcached网络IO模型）</p>
<p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。</p>
<h3 id="2-内存管理方面"><a href="#2-内存管理方面" class="headerlink" title="2. 内存管理方面"></a>2. 内存管理方面</h3><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔除，原因可以参考文章：<a href="https://hcldirgit.github.io/2017/08/23/Memcached/4.%20Memcached%E6%95%B0%E6%8D%AE%E8%A2%AB%E8%B8%A2(evictions0" target="_blank" rel="external">Memcached数据被踢(evictions0)现象分析</a>%E7%8E%B0%E8%B1%A1%E5%88%86%E6%9E%90/)</p>
<p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非临时数据（但会尝试剔除部分临时数据），这点上Redis更适合作为存储而不是cache。</p>
<h3 id="3-数据一致性问题"><a href="#3-数据一致性问题" class="headerlink" title="3. 数据一致性问题"></a>3. 数据一致性问题</h3><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断。</p>
<h3 id="4-存储方式及其它方面"><a href="#4-存储方式及其它方面" class="headerlink" title="4. 存储方式及其它方面"></a>4. 存储方式及其它方面</h3><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能</p>
<p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS</p>
<p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。</p>
<h3 id="5-关于不同语言的客户端支持"><a href="#5-关于不同语言的客户端支持" class="headerlink" title="5. 关于不同语言的客户端支持"></a>5. 关于不同语言的客户端支持</h3><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。</p>
<p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;根据以上比较不难看出，当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适。</p>
<h2 id="关于Redis的一些周边功能"><a href="#关于Redis的一些周边功能" class="headerlink" title="关于Redis的一些周边功能"></a>关于Redis的一些周边功能</h2><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原理，清楚地了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢失的，又比如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。</p>
<p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。</p>
<h2 id="总结："><a href="#总结：" class="headerlink" title="总结："></a>总结：</h2><ol>
<li>Redis使用最佳方式是全部数据in-memory。</li>
<li>Redis更多场景是作为Memcached的替代者来使用。</li>
<li>当需要除key/value之外的更多数据类型支持时，使用Redis更合适。</li>
<li>当存储的数据不能被剔除时，使用Redis更合适。</li>
</ol>

	

	
		<span class="different-posts"><a href="/2017/10/12/Redis/14. 为什么使用 Redis及其产品定位/" onclick="window.history.go(-1); return false;">⬅️ Go back </a></span>

	

</article>

	</main>

	<footer class="footer">
	<div class="footer-content">
		
	      <div class="footer__element">
	<p>Hi there, <br />welcome to my Blog glad you found it. Have a look around, will you?</p>
</div>

	    
	      <div class="footer__element">
	<h5>Check out</h5>
	<ul class="footer-links">
		<li class="footer-links__link"><a href="/archives">Archive</a></li>
		
		  <li class="footer-links__link"><a href="/atom.xml">RSS</a></li>
	    
		<li class="footer-links__link"><a href="/about">about page</a></li>
		<li class="footer-links__link"><a href="/tags">Tags</a></li>
		<li class="footer-links__link"><a href="/categories">Categories</a></li>
	</ul>
</div>

	    

		<div class="footer-credit">
			<span>© 2017 失落的乐章 | Powered by <a href="https://hexo.io/">Hexo</a> | Theme <a href="https://github.com/HoverBaum/meilidu-hexo">MeiliDu</a></span>
		</div>

	</div>


</footer>



</body>

</html>
